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ABSTRACT 

The Orbital Maneuvering Vehicle (OMV) will 
be remotely piloted during rendezvous, 
docking, or proximity operations with 
target spacecraft from a ground control 
console (GCC). This paper describes the 
real-time mission simulator and graphics 
being used to design a console pilot- 
machine interface. 

A real-time orbital dynamics simulator 
drives the visual displays. The dynamics 
simulator includes a J2 oblate earth grav- 
ity model and a generalized 1962 rotating 
atmospheric and drag model. The simulator 
also provides a variable-length communica- 
tion delay to represent use of the Track- 
ing and Data Relay Satellite System 
( TDRSS ) and NASA Communications (NASCOM). 

Input parameter files determine the graph- 
ics displays. This feature allows rapid 
prototyping since displays can be easily 
modified from pilot recommendations. Dif- 
ferent subsets of OMV telemetry data can 
be shown to determine the information 
necessary for pilot operations. 

A series of pilot reviews are being held 
to determine an effective pilot-machine 
interface. Pilots fly missions with 
nominal to 3-sigma dispersions in trans- 
lational or rotational axes. Console 
dimensions, switch type and layout, hand 
controllers, and graphic interfaces are 
evaluated by the pilots and the GCC simu- 
lator is modified for subsequent runs. 
Initial results indicate a pilot prefer- 
ence for analog versus digital displays 
and for two 3-degree-of -freedom hand 
controllers . 

INTRODUCTION 

The OMV is designed as a reusable unmanned 
spacecraft. Initially deployed from the 
space shuttle, it is capable of staying in 
orbit for months while receiving periodic 
on-orbit maintenance and refueling. The 


OMV is used to deliver, retrieve, reboost, 
or maneuver satellites between the shuttle 
or space station and a specific orbit. 

The OMV flies autonomously to within 1000 
feet of a target spacecraft. A pilot then 
remotely controls the OMV in rendezvous, 
docking, or proximity operations. The OMV 
will be operated by NASA personnel from a 
ground control console (GCC) located at 
the Johnson Space Center. 

The GCC sends pilot commands to the OMV 
via NASA Communications (NASCOM) and two 
Tracking and Data Relay Satellites (TDRS). 
The OMV downlink transmissions consist of 
telemetry and two video camera transmis- 
sions. The communications link can trans- 
mit up to 32 kilobits/second of telemetry 
and 1 megabit/second of compressed video 
signal. The communications link has an 
approximate 3-second round-trip delay 
time . 

The OMV docks with the target spacecraft 
using either the remote manipulator system 
(RMS) grapple docking mechanism ( RGDM) or 
a three-point docking mechanism (TPDM) for 
those spacecraft that have a flight sup- 
port system (FSS) interface. 

The OMV prime contractor, under NASA 
Marshall Space Flight Center, is TRW. 

The OMV is scheduled for deployment in 
November 1993. Its potential first mis- 
sion is in conjunction with the Waves in 
Space Plasma (WISP) project. 

OMV flight operations will be conducted 
from either of two identical GCCs . A GCC 
provides pilot control of the OMV during 
all flight operation phases. Each GCC 
consists of switches, hand controllers, 
two terminals and keyboards, data proces- 
sing equipment, and two monitors display- 
ing information from the on-board docking 
and pan/tilt/zoom (PTZ) video cameras. 

The pilot manipulates hand controllers for 
OMV maneuvers and utilizes switches for 
OMV or console commands . 
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The GCC must provide a pilot-machine 
interface that gives adequate information 
to avoid information overload, and mini- 
mizes pilot errors. TRW was given the 
task of building a prototype GCC (PGCC) to 
simulate man-in-the-loop, real-time remote 
OMV teleoperations. The PGCC is the tool 
used to establish the console pilot- 
machine interface. 

SIMULATOR OVERVIEW 

Simulator Models 

The PGCC was developed as a representative 
operational pilot station used for pre- 
liminary design evaluations and crew 
reviews. The OMV program concluded that 
to evaluate a pilot-machine interface 
fully, it was necessary to simulate a 
dynamic docking environment which inte- 
grates flight telemetry with hand-eye 
coordination. Space environment and OMV 
models are included in the simulation. 

The simulator dynamically models the space 
environment. The environment models 
include a J2 oblate earth gravity model 
and a generalized 1962 rotating atmos- 
pheric density and velocity model. A drag 
model is based on a cylindrical approxima- 
tion for the OMV and target bodies . 

Each body is characterized by 6-degree-of- 
freedom (DOF) equations of motion includ- 
ing effects of position, velocity, atti- 
tude, translational and rotational rates, 
moments of inertia, centers of mass, and 
gravity gradient torques . Each target 
satellite is in free drift and has no 
control system. Only the OMV has thrus- 
ters and a flight control system. 

Mission date and time parameters position 
the sun, moon, and earth in the simulator 
reference frame. Other mission parameters 
determine orbit position and velocities. 
Positions of the OMV during the simulation 
determine sun occlusion, camera sun intru- 
sion, and communication zones of exclu- 
sion. They also affect lighting condi- 
tions and shading. Without these real- 
world conditions, valid data cannot be 
taken. 

The simulator models several OMV subsys- 
tems. These include the fuel system, 
radar, and two video cameras. For exam- 
ple, the pilot may select either a hydra- 
zine or GN 2 thruster system during flight. 
Each alternative has its own fuel tanks 
and rates of consumption. The hydrazine 
tanks are manifolded while the GN 2 tanks 
are independent . 

Each fuel system has its own set of 
thrusters. Input parameter files 
determine the location, force vector, and 
impulse moment of each thruster. A 
particular thruster is rendered useless 
when the fuel tank feeding that thruster 


is empty. Deviation in thruster force is 
modeled by varying the force vectors in a 
parameter file. Simulator logic is used 
to model the less efficient first few 
microseconds of burn. A thruster pulse 
size, initialized by an input parameter, 
determines the minimum burn allowed. 
Individual thrusters can be failed on or 
off. If a thruster is failed off, no 
force or fuel is spent. However, if a 
thruster fails on, fuel will be burned and 
corresponding impulse moments will occur. 

Pilots maneuver the OMV by commanding 
thruster burns in one or more axes . The 
simulated on-board computer receives the 
axis thrust commands and uses a jet select 
table to compute thruster burn times. The 
simulator provides two jet select tables. 
The real OMV utilizes identical jet select 
information which is uplinked to the 
vehicle during preflight checkout. 

The simulator also models the OMV radar 
subsystem. A pointing vector from the 
radar mount to the target is computed. 

This vector takes into account the OMV 
position, gimbal limits, and radar field 
of view. The simulator computes the 
azimuth, elevation, azimuth rate, and 
elevation rate from the pointing vector. 
The radar also models the radar-to-target 
surface range and range rate. Radar noise 
and bias are introduced into the range and 
range rate data for greater realism. The 
models also provide maximum and minimum 
radar cutoff points at selectable 
distances . 

The simulator models the docking (bore- 
sight) and PTZ cameras. They both produce 
black and white video. The pilot operates 
either a joystick or switches on the PGCC 
console to tilt, pan, or zoom the PTZ 
camera to a commanded position with 
corresponding slew rates. 

Each camera has a 30-degree half-angle 
field of view. Gimbal stops limit the PTZ 
camera range of motion. Each camera is 
equipped with a sensor to detect sun 
brightness. If sun intrusion should 
occur, the shutter of the camera will 
close, blinding that camera. 

Contact detection and limited dynamics are 
modeled in the simulator. Since modeling 
full contact dynamics between all surfaces 
of the OMV and its target is impractical 
without additional computing power, the 
simulator detects contact only between the 
open or closed TPDM latches and target 
trunnions. The simulator computes contact 
dynamics with a method of "soft con- 
straints.” This technique allows solids to 
penetrate each other at the point of con- 
tact. The algorithm then computes the 
restoring normal and tangential forces 
based on the depth of penetration. Damp- 
ing forces also may be added. In addi- 
tion, sliding (Coulomb) and viscous 
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friction may be applied. Linear and 
angular momentum is conserved upon 
contact for complete 6-DOF motion. 

The OMV model contains a flight control 
system. The system uses the earth 
centered inertial (ECI) or local-vertical 
local-horizontal ( LVLH ) reference frames. 

A three-axis linear control law fires 
thrusters if either attitude or attitude 
rates exceed a selectable deadband. Atti- 
tude or rate hold is disabled for an axis 
if a pilot commands a maneuver in that 
axis. In addition, an automatic attitude 
maneuver capability is built into the 
simulator. The simulator rotates the OMV 
by firing thrusters to the desired 
attitude commanded by the pilot. 

The OMV uses two high-gain antennas ( HGA) 
to communicate with the TDRSS spacecraft. 
The simulator maintains a pointing vector 
from each HGA to each TDRS . Communication 
zones of exclusion are based on the orbit, 
ECI satellite positions and velocities, 
earth occultation, and HGA gimbal limits. 

Simulator Interfaces and Architecture 

The simulator provides several interfaces 
in addition to the pilot-machine inter- 
face. The simulator operator has a 
telemetry and data display on a side 
terminal. The operator can introduce 
anomolies from either this terminal or 
from an event file. The event file, read 
in at initialization, is a list of com- 
mands and events that occur at some speci- 
fied time into the simulation. The opera- 
tor also receives history and contact 
report files for post-simulation analysis. 
The history file contains all OMV and 
target state vector information, switch 
inputs, and environment information. The 
contact report file contains time-stamped 
contact information. 

Nearly all simulator data is initialized 
by input parameter files. These files 
determine values such as fuel and thruster 
characteristics, orbit position, environ- 
ment data, mass properties, and size of 
the OMV and target. They also initialize 
such other data as the number of targets, 
placement of the video camera, radar 
characteristics and all simulator control 
information. 

Orbit characteristics determine initial 
orbit placement and rates. This data can 
be specified in osculating mean of 1950 
(OM50), rectangular mean of 1950 (RM50), 
inertial mean of launch date (IMLD), or 
target relative reference frames. State 
vector integration and derivatives are 
computed using quaternions. Forces and 
accelerations due to gravity, torques, and 
thrusters are computed using the Adams - 
Moulton integrator. 


The simulator maintains its own time with 
software interrupts. Each major subsec- 
tion is given a constant delta time each 
cycle to perform its tasks. For example, 
the input subsection reads the joysticks 
and switches every 50 milliseconds. The 
on-board computer (OBC) subsystems are 
executed every 250 milliseconds and 
graphic displays are updated every 200 
milliseconds. This approach simplifies 
the software architecture, eliminating 
separate processes and semaphores . 
However, one slow subsection can degrade 
the entire simulation. 

The simulator hardware consists of a 
MicroVAX 3600, Chromatics CX2000 with 
frame grabber and a 24-bit z-buffer. The 
CX2000 drives two 1280 x 1024 pixel 
19-inch monitors. A Q-bus Direct Memory 
Access (DMA) connects the MicroVAX with 
the CX2000. The simulator drives two 
pilot consoles, each containing hand 
controllers and up to 48 switches. The 
simulator is built from approximately 
17,000 lines of FORTRAN. 

PILOT-MACHINE INTERFACE 

Interface Description 

The main PGCC task is to define a pilot- 
machine interfaces the physical console 
and graphic displays. The console inter- 
face consists of console dimensions, hand 
controllers, and placement, function, and 
choice of switches. The console ergonom- 
ics are designed to accommodate the 95th 
percentile man and 5th percentile woman 
(Figure 1 ) . 



Figure 1. Prototype Ground Control 
Console 


The selection, placement, and style of 
telemetry and video data form the second 
part of the pilot interface. A language 
was created to express overlay character- 
istics and to allow easy reconfiguration. 
Input parameter files, written in this 
language, define the color, placement. 
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style, etc. of each overlay. In this 
way, per-simulation customization can take 
place. In addition, alternate styles of 
display, graphic or text, can both be 
accommodated (Table I), Merely changing 
the input files drastically alters the 
"look and feel" of the pilot-machine 
interface. Figure 2 shows a current set 
of piloting overlays. 

Table I. Overlay Definition File 


* 

* TPDM Docking Overlay 

* 

BEGIN_ICON NEAR_FIELD 
OVERLAY 0 

OFFSET 100.0 73.242 
SCALE 1.0 1.0 1.0 
ROT 0.0 
SUB_ICON 

COLOR WHITE 
OFFSET 0.0 0.0 

* Vertical Ranging Marks 

* 10 feet out 

LINE -4.736 2.0 -4.736 -2.0 
LINE 4.736 2.0 4.736 -2.0 

* 3 feet out 

LINE -15.787 2.0 -15.787 -2.0 
LINE 15.787 2.0 15.787 -2. 

* Minimum docking range 

LINE -21.714 2.0 -21.714 -2.0 
LINE 21.714 2.0 21.714 -2.0 
END_SUB_ICON 
END_ICON 

* 

BEGIN_ICON DOWNJTHRUST 
OVERLAY 1 
SUB_IC0N 

OFFSET 3.5 1.0 

ROT 270.0 
SCALE 1.0 1,0 1.0 
FILLED 
COLOR CYAN 
ARROW 
ARC 90.0 
END_SUB_ICON 
SUBJTEXT 

HEIGHT 2 
EXPAND 1.0 
RIGHT 

STRING Rate: 

ENDJSUBJTEXT 
END ICON 


DOCKING INTERFACE 

The pilot operates hand controllers and 
switches to guide the OMV to a dock with 
the target vehicle. The OMV is equipped 
with one of two types of grappling mecha- 
nisms depending on the target vehicle 
interface. Two standard mechanisms 
include the RGDM or the TPDM. The current 
simulator configuration models the TPDM 
with the Hubble Space Telescope. After 
the pilot maneuvers the OMV within the 
docking envelope, the three TPDM latches 


can be independently closed, ensnaring the 
trunnions mounted on the aft of the Space 
Telescope . 

The pilot uses the docking target located 
on the back face of the target satellite 
as a guide when docking. The target, in 
relation to the docking overlay, gives the 
pilot relative translation and rotation 
information. When the docking target 
fills the docking overlay, the target 
trunnions are within the grapple capture 
envelope . 

Each TPDM latch mechanism is equipped with 
two sensor beams . When the trunnion 
breaks a sensor beam, the corresponding 
grapple beam overlay changes color. Using 
the overlays and video, the pilot can 
accurately determine the position and 
attitude of the target relative to the 
OMV. 

Attitude errors discernible from the Space 
Telescope docking target are larger than 
the TPDM will accommodate. Therefore, the 
docking overlay is built to give the pilot 
information on maximum attitude and trans- 
lational docking allowances. With this 
overlay, the pilot can back out, if neces- 
sary, to realign the OMV with the target 
for a safer dock. If the docking target 
should exceed the overlay, the pilot can 
expect the latches to contact the trun- 
nions. The overlay provides the allowances 
at the minimum docking range (when the 
trunnion are just within the docking 
envelope) and at the point when the trun- 
nions are centered over the second (inside) 
beam . 

Astronaut comments indicate that range and 
range rate information is especially 
important within the radar cutoff point. 
Since acceptable latch closure rates are 
0 . 1 foot/second along any axis and 0 . 5 
foot/second about any axis, it is important 
the pilot get an accurate "feel" for the 
OMV ' s closing rate. Therefore, ranging 
aids were built into the docking overlay. 

PILOT REVIEW 

Approach 

The first in a series of simulator reviews 
was held in August 1988. Thirteen people 
from TRW, Johnson Space Center, and 
Marshall Space Flight Center, including 
two astronauts, were available as pilots. 
The pilots ran through a sequence of 
training procedures to familiarize 
themselves with switch layouts, OMV 
thruster sensitivity, docking procedures, 
and overlays. After being "qualified," 
each pilot ran a set of simulations 
emulating various mission phases. Initial 
conditions ranged from nominal to 3-sigma 
cases in translational or rotational rates. 
Overlays were explained prior to each 
training procedure. Piloting tips were 
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Figure 2 . Pilot Overlays 
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provided and any questions were answered 
during the simulation. Pilots flew 
simulations during eclipse and docked with 
spinning targets. A history log was kept 
of each procedure and simulation for 
analysis. After each training procedure 
and simulation , pilots were debriefed. The 
total flight time exceeded 40 hours. 
Training time was limited to approximately 
1 hour per pilot. The time for each run 
varied between 10 and 30 minutes. 

The first review focused on two variables: 
text versus graphic displays and type of 
hand controller. Although these were the 
primary concerns, other feedback was also 
noted . 

Review results were based on observations 
during flight simulations and pilot 
feedback gained from questionnaires and 
discussions. The evaluation focused 
primarily on the reasons for the success or 
failure to reach the simulation goal. 


Initial Results 

The review clearly showed a pilot 
preference for a hybrid of primarily 
graphic overlays mixed with some text . 

There were varying opinions expressed on 
the graphic versus text attitude direction 
indicator (ADI) format. In future reviews, 
pilots will select an ADI format from a 
palette of four displays. Digital range 
and range rate will be added to the 
enlarged analog radar display. The radar 
display will be enlarged to detect azimuth 
and elevation rates more easily. 

Some of the overlays are placed directly on 
top of the video. These were difficult to 
see at times due to the underlying video 
color. Since the video contrast varies 
during orbit, there is a need to 
dynamically change the color of the 
overlays during simulation. One overlay 
color may be acceptable during one mission 
phase but not during another. 

Pilots flew with targets spinning at 1.0 
degree/second. It was apparent that the 
piloting techniques vary sufficiently to 
warrant another type of docking overlay. 
Specific aids for matching target spin 
rates and tracking rotating targets will be 


included with the standard ranging informa- 
tion and docking allowance overlays. 

Overall, the pilots liked the console ergo- 
nomics. Most preferred an adjustable tilt 
monitor. They were pleased with the 
monitor size and resolution. Pilots flew 
with both types of displays and hand 
controllers. One console had two 3-DOF 
hand controllers and the other had one 
6-DOF controller with a different 
assortment and arrangement of switches . 
Switches varied in type, shape, color, and 
mounting. Pilots indicated that switch 
shape, size, or mounting did not aid in 
correct switch selection. Most pilots 
preferred flush-mounted switches. 

Unverified piloting switch commands are 
indicated by flashing switches. The switch 
light changes color after the command has 
been verified or executed. This scheme 
worked well; most pilots did not prefer any 
other method. 

Most pilots were trained to fly with two 
3-DOF hand controllers and preferred to 
continue using them rather than the one 
6-DOF controller. 

CONCLUSION 

It is evident that a full dynamic 
simulation is prerequisite to gaining 
useful data. Comments on an interface from 
an unrealistic simulator would have limited 
use. Likewise, trained pilots are needed 
to produce valid conclusions and avoid 
review comments which merely reflect 
unfamiliarity with the simulator, overlays, 
or piloting techniques . 

The choice of pilot missions also 
influences the quality of gathered 
information. Carefully planned missions 
which stress pilot or OMV performance are 
most useful; during nominal missions, 
nearly all displays either work well or are 
never used. 

By holding a series of pilot reviews and by 
building prototype displays, agreement will 
be reached on an acceptable pilot-machine 
interface. It is expected that having a 
community consensus on an OMV pilot-machine 
interface will prevent problems during the 
acceptance phase of the GCC project. 
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